\chapter{Discussion \& Recommendations}

\section{Limitations of prototype}

There are few limitations we have discovered during the development and testing of the LAMS prototype. The following section describes general performance issues for LAMS if it were to be commercialised and deployed by VoIP service providers.

\subsection{Geographic \& Latency issues}

As LAMS clients connect to the LAMS server using first person shooter network technology, it is preferrable that LAMS clients are situated as close as possible to the LAMS server (idealy on the same subnet) based on \cite{Quake3Latency}. Being in a close proximity to the server reduces the time packets need to travel from the LAMS server to client (Figure \ref{fig:clientTraffNoMove}). This would improve the task of real time monitoring VoIP servers. Also based on traffic analysis (Figure \ref{fig:clientTraffwMove}), a constant network connection is needed from the LAMS client to server. Packet delay and loss may occur if a LAMS client were to connect over the Internet.

VoIP servers can be located around Victoria as the traffic produced to the LAMS server by each is not negligible (Figure \ref{fig:gangliaTraff1pbx}). Though latency can be a problem with VoIP system updates sent to the LAMS server.  Delayed and lost updates may cause false readings by network administrator using the LAMS system. A VoIP server may have a system failure but if the update containging this information is not sent, the LAMS server would display the VoIP server as being fine.

A real life implementation of LAMS would need to ensure that update packets from the VoIP server are received at a timely manner to ensure near real time monitoring.

\subsection{Maximum Cluster size of VoIP servers}

Based on our performance tests, it is clear that LAMS can easily handle up to 4 LAMS clients \ref{fig:lamsCPU}. It can be safely said that up to 8 clients can provide collaborative monitoring of our prototype system assuming that the CPU usage is doubled from that of 4 clients.

There is also a limit to how many VoIP servers and clients the current LAMS prototype can manage. The current prototype uses L3DGEWorld 2.3 as a visualisation tool which has a hard coded maximum of 1023 entities (in l3dgeworld 2.3 source code q\_shared.c and tr\_types.c) that can be displayed.

This concludes that our current prototype could manage many variations of the number VoIP servers and clients with the condition that the number of VoIP servers plus VoIP clients must be under the maximum entity number. 
This leaves us with the following equation:
\begin{equation}
No. of VoIP Server * No. of Clients = Maximum No. of L3DGEWorld Entities
\end{equation}

If we set the number of clients to 90 (which was discovered to be just under the maximum calls Asterisk would process with a default configuration), this results in our LAMS system being able to manage at least 11 VoIP servers. 

If LAMS were to be implemented, a VoIP company such as Engin \cite{www:engin}, Iinet \cite{www:iinet} and Pennytel \cite{www:pennytel} services  up to and more than 88,000 of VoIP customers. Our current solution would possibly require these companies to have 977 LAMS servers which can run on relatively cheap or existing hardware. 


\subsection{VoIP Server update intervals}
Initial updates of Asterisk were slower than expected by our solution in Appendix \ref{ganglia}. 18 seconds updates is far too slow as calls can be made and not detected during this short period.  This was due to the Asterisk Manager Interface \cite{www:ami} being a timely process to extract telephony statistics from Asterisk PBX. A more elegant solution if development time was possible is to implement a LAMS module within Asterisk's open source code.  

In a commercial development of LAMS, Grazer would need to update the state of the quick enough to detect the shortest phone calls. This would in theory increase the network traffic produced to monitor each VoIP server if update intervals were increased. The CPU load and memory use would also increase as entities in the LAMS virtual world are constantly being updated. 


\subsection{Limited Telephony Monitoring \& Managemen}

Telephony statistics such as what calls are in a queue, any errors the VoIP server encounters are not monitored by our prototype. A commercial implementation of LAMS would need to incorporate features such as lawful interception, explicit hanging up of calls and some sort of call recording feature. 

Another features that would be useful for VoIP administrators is integration of the visual monitoring tool with the customer and billing database.

\subsection{Security Implementation}

Currently the prototype does not implement any security between the VoIP server and LAMS server. In a commercial implementation of LAMS, important and confidential information will be sent across a public network.  One possible notion is to use a VPN connection from LAMS server to VoIP server or to encrypt the packets instead. A quick traffic capture of ganglia packets showed that information is sent in clear text. 

\begin{figure}[htp]
\includegraphics[width=\columnwidth]{diagrams/gangliaCapture.png}
\caption{Ganglia updating VoIP servers in clear text.}
\label{fig:gangliaCapture}
\end{figure}


\section{LAMS - 2D verses 3D visual monitoring}

2D and 3D visualization of system metrics for VoIP monitoring both have thier advantages. Contrasting the web interface representation that Ganglia provided and LAMS virtual world representation, we use the notion of "how many calls" are being made through a VoIP server as an example.

In the 3D representation, the instantaneous number of calls being made is depicted by how many IP phones are moving in the room. A 2D representation from Ganglia web monitoring is a histogram of the number of calls.  Figure \ref{fig:2Dvs3D} contrasts both representations. 


\begin{figure}[htp]
\includegraphics[width=\columnwidth]{diagrams/2Dvs3D.pdf}
\caption{2D vs 3D call monitoring. 2D (left) shows a history of how many calls were made and 3D (right) shows the current number of calls.}
\label{fig:2Dvs3D}
\end{figure}

LAMS purpose is to monitor VoIP servers in real time giving network administrators the ability to respond to a system problem or even prevent failure of the system quickly. Perhaps a combination of both 2D and 3D would be work together to provide a better monitoring solution. 







